Traditional client-server systems employ a two-tiered architecture such as that illustrated in FIG. 1A. Applications 102 executed on the client-side 100 of the two-tiered architecture are comprised of a monolithic set of program code including a graphical user interface (GUI) component, presentation logic, business logic and a network interface that enables the client 100 to communicate over a network 103 with one or more servers 101. A database 104 maintained on the server 101 provides non-volatile storage for the data accessed and/or processed by the application 102.
As is known in the art, the “business logic” component of the application represents the core of the application, i.e., the rules governing the underlying business process (or other functionality) provided by the application. The “presentation logic” describes the specific manner in which the results of the business logic are formatted for display on the user interface. The “database” 104 includes data access logic used by the business logic to store and retrieve data.
The limitations of the two-tiered architecture illustrated in FIG. 1A become apparent when employed within a large enterprise. For example, installing and maintaining up-to-date client-side applications on a large number of different clients is a difficult task, even with the aid of automated administration tools. Moreover, a tight coupling of business logic, presentation logic and the user interface logic makes the client-side code very brittle. Changing the client-side user interface of such applications is extremely hard without breaking the business logic, and vice versa. This problem is aggravated by the fact that, in a dynamic enterprise environment, the business logic may be changed frequently in response to changing business rules. Accordingly, the two-tiered architecture is an inefficient solution for enterprise systems.
In response to limitations associated with the two-tiered client-server architecture, a multi-tiered architecture has been developed, as illustrated in FIG. 1B. In the multi-tiered system, the presentation logic 121, business logic 122 and database 123 are logically separated from the user interface 120 of the application. These layers are moved off of the client 125 to one or more dedicated servers on the network 103. For example, the presentation logic 121, the business logic 122, and the database 123 may each be maintained on separate servers, 126, 127 and 128, respectively.
This separation of logic components and the user interface provides a more flexible and scalable architecture compared to that provided by the two-tier model. For example, the separation ensures that all clients 125 share a single implementation of business logic 122. If business rules change, changing the current implementation of business logic 122 to a new version may not require updating any client-side program code. In addition, presentation logic 121 may be provided which generates code for a variety of different user interfaces 120, which may be standard browsers such as Internet Explorer® or Netscape Navigator®.
The multi-tiered architecture illustrated in FIG. 1B may be implemented using a variety of different application technologies at each of the layers of the multi-tier architecture, including those based on the Java 2 Platform, Enterprise Edition™ (J2EE) standard, the Microsoft®NET™ standard and/or the Advanced Business Application Programming™ (ABAP) standard developed by SAP AG.
For example, in a J2EE environment, such as the one illustrated in FIG. 1C, the business layer 122 is to handle the core business logic of the application having Enterprise JavaBean™ (EJB or enterprise bean) components with support for EJB containers 134. While the presentation layer 121 is responsible for generating servlets and Java ServerPages™ (JSP or JSP pages) interpretable with support for Web containers 132 by different types of browsers at the client 125 via a web server 136 a network 103 (e.g., Internet or intranet).
In recent years, as business application development projects have grown larger and more diversified, integration of business applications in terms of people, information, and processes is becoming increasingly important. SAP® NetWeaver™ was developed and presented by SAP AG with core capabilities to provide a solution for the integration of people, information, and processes.
However, the integration of people, information, and processes is resulting in an ever increasing demand for high-level planning, maintenance, and administration, which in turn, requires the underline architecture and environment to conform to, for example, platform independence, inter-process communication, increased security, development versioning, multi-user possibility, and shared memory. For example, it would be useful to have an architectural environment that provides increased robustness, improved integration, better monitoring, reduced memory footprint, decreased internal threads, faster session failover, and shared memory.
In contrast to existing native binary applications, which are usually loaded into the system memory before executing the application, the Java programming language provides another concept of loading application code. Java classes which contain the executable program code are loaded on demand by class loaders. This means that a class is only loaded when it is used for the first time. This enables lazy initialization, which means that certain parts of the application which are not used will not be loaded and do not consume memory resources. This also allows certain parts of an application to be unloaded if they are not used anymore.